Real time text (RTT) allows for a near instantaneous transmission of text content between Internet Protocol (IP)-based terminals. As a user of a source device types a RTT message, the text content of the RTT message is (without providing a “send” button for the user to select) transmitted to, and displayed on, a destination device in real-time. The transmission of text content can occur character-by-character such that the user of the destination device may see each character appear on the display of the destination device in real-time, as the characters are typed by the user of the source device. This near instantaneous transmission of text content resembles a more natural conversation that is preferred by the hearing and speech impaired over traditional text messaging (e.g., Short Message Service (SMS) text). However, this near instantaneous transmission of text content can also cause challenges in presenting the text content on a display in a way that is user-friendly and easy for a user to visually follow the written conversation.
For instance, if RTT content is to be displayed within conversation bubbles using a “strictly sequential” approach for displaying text characters as they are received by the device (either through direct user input or over a network from another device), the resulting written conversation may be displayed in an overly interrupted or fragmented manner that is difficult, if not impossible, to follow. Using this strictly sequential approach, phrases, and even individual words, may be fragmented across the display in multiple conversation bubbles, rendering words illegible and phrases difficult to piece together. For example, text characters of a single word may be distributed across different conversation bubbles on the display because each party of the conversation may be typing at nearly the same time, interrupting the other party's thought. In an extreme example, during a RTT session between User A and User B, User A may type a text character of a word, which is displayed in a first conversation bubble at the top of the screen, which is followed by User B typing a text character of a word, which is displayed in a different conversation bubble below User A's first conversation bubble, which is followed by User A typing yet another text character of the same, original word, which is displayed in yet another conversation bubble below User B's conversation bubble, and so on and so forth. It can be appreciated that a written RTT conversation can appear extremely fragmented and illegible on a display using a strictly sequential approach, as described above. At the other extreme, if each user's RTT content were to be displayed in a single conversation bubble designated for each user, the written conversation would lose its natural back-and-forth sequence, which, in its own right, makes the written conversation difficult, if not impossible to follow on a display.
Traditional messaging applications, like SMS, do not experience these challenges because text content of traditional messaging applications is not transmitted over the network unless and until a user selects the “send” button. Thus, in traditional messaging applications (i.e., non-RTT messaging applications) a user can type out a complete thought before deciding to select the “send” button. Upon selecting the send button, a conversation bubble is created containing the user's complete thought. In RTT communication sessions, the omission of this “send” button, coupled with the fact that text content is transmitted in real-time (i.e., near instantaneous transmission of text content), without user intervention, presents unique challenges to presenting a written RTT conversation using conversation bubbles such that the written conversation is easy for a user to visually follow on a display.